Remarks 

Applicant respectfully requests reconsideration and allowance of the 
subject application. Claims 1, 2, 4, 12 are amended and claims 33- 56 are added, 
support for which may be found throughout the specification and drawings as 
filed. Accordingly, Claims 1-13 and 33-56 are pending. 

35 U.S.C. S102 (b) Rejection 

Claims 1, 2, 4, 5 and 13 are rejected under 35 U.S.C. §102 (b) as being 
anticipated by U.S. Patent No. 5,586,260 to Hu (hereinafter, "Hu") See Office 
Action, Page 4. Applicant respectfully traverses the rejection and reserves the right 
to rebut the use of Hu as a reference at a later time. The claims are amended to 
increase clarity and not in response to the asserted references and therefore the 
Applicant will address the original rejections below. 

Hu describes a method and corresponding apparatus for authenticating a 
client for a server when the client and server have different security mechanisms. 
An authentication gateway authenticates a client using the client security 
mechanism and impersonates the client in a call to a server that the client wishes 
to access. Thus, the communications between the client and the server are passed 
through the authentication gateway. "When the client wishes to call the server, the 
client calls the authentication gateway acting as a proxy server, and passes the 
access key, which is then used to retrieve the security credentials and to 
impersonate the client in a call to the server. Any output arguments resulting from 
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the call to the server are returned to the client through the authentication gateway." 



See Hu, Abstract. Hu also describes that a proxy server (residing on the 

authentication gateway) brokers communications between a user and a server 

when the user does not conform to the security protocol of the server. According 

to Hu, a client does not need to be registered with a proxy server that it might use. 

Regarding claim 1, the Examiner asserts that Hu "...discloses a method for 

communication over a network that allows for the authentication of individuals 

and control of information comprising: registering with a discovery machine a first 

user and second user, wherein the first user maintains a first client machine and 

the second user maintains a second client machine, wherein the first client 

machine, the second client machine and the discovery machine are coupled to a 

network" See Office Action, Page 4. The Examiner cites the following portion of 

Hu in rejecting this feature: 

Fig. 3 takes the explanation of the authentication scheme one 
step further, and shows diagrammatically the sequence of 
steps followed by each of the systems in handling access to 
the server 12 by a client system 10 not conforming with the 
security mechanism of the server. The client system 10 
includes a log-in procedure 30, and a client application 
process 32 from which a server request will emanate. The 
log-in procedure 30 is executed, as its name implies, only 
infrequently, such as once a day. Part of the log-in procedure 
is a call to the authentication gateway 22 to permit 
authentication within the client security domain. This call, 
indicated by line 34 carries as parameters the identity of a 
client and any necessary password or security code needed to 
satisfy the security requirements of the client security domain. 
The authentication gateway 22 performs the operations 
necessary to verify the authenticity of the client 10. The 
authentication gateway 22 acquires authentication credentials 
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for the client and saves them for later use. The authentication 
gateway 22 then returns to the log in procedure 30, over line 
36, an identifier that confirms authentication of the client. The 
log in procedure 30 stores the returned identifier in an id 
cache 38. This completes the first phase of operation of the 
gateway, which has authenticated the client within the client's 
security domain and has stored a confirming identifier in the 
cache 38, over line 40 for later use by the client. See Hu, Col. 
4, Lines 1 7-43. 

Hu does not in fact disclose registration of a first or second user. Indeed, Hu 
teaches away from registration, as shown in the following portion of Hu, "Further, 
the proxy server has no significant management overhead. The proxy server does 
not store a client's secret key (server based id) and does not need to manage user 
accounts. For example, a client does not need to be registered with a proxy server 
that it might use." See Hu, Col. 7, Lines 11-16 (emphasis added). Accordingly, Hu 
does not disclose registration as asserted by the Examiner. 

The Examiner further rejects claim 1 asserting that Hu discloses, "the 
discovery machine establishing a direct link between the first client machine and 
the second client machine; and delivering the communication" See Office Action, 
Page 5. Additionally, the Examiner asserts that "in response to applicant's 
arguments that Hu does not suggest that a direct link is established between the 
first client machine and the second client machine because Hu discloses that 
communications between the client and the server are communicated via the proxy 
server.. . .this argument is not persuasive because after a client establishes access to 
a remote server via the gateway system, Hu discloses that the proxy server 
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merely forwards the communication between the client and the remote server 

(Col. 3:54-56)". See Office Action, Pages 2-3 (emphasis added). Thus, the 
Examiner admits that Hu discloses that the proxy server is used during 
communication between the first and second client machines. The Applicant 
respectfully submits that this communication is not direct, as the proxy server is 
actively involved in forwarding communication between the client and the remote 
server. Claim 1, however, recites "said communication is not delivered through 
said discovery machine" which as admitted by the Examiner is not disclosed by 
Hu. 

The Examiner also asserts that this reasoning "conforms to the enabling 
portion of applicant's specification which describes an embodiment wherein a 
direct link is established between two clients. See pg. 18, paragraph 83." See 
Office Action, Page 3. The Applicant respectfully submits that there is no 
statutory basis that permits the Examiner to add a portion of the specification sua 
sponte in making a rejection of a claim and therefore this portion of the rejection is 
respectfully submitted to be erroneous. Withdrawal of the rejection is respectfully 
requested. 

Claims 2, 4, 5 and 13 are allowable as depending from an allowable base 
claim. Each of the dependent claims is allowable based on the same rationale 
discussed with respect to claim 1 . These claims are also allowable for their own 
recited features which, in combination with those recited in claim 1, are neither 
shown nor suggested in the references of record, either singly or in combination 
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with one another. 

For example, the Examiner does not cite any portion of Hu in rejecting 
claim 2. As the Examiner is aware, the Examiner "ordinarily should reject each 
claim on all valid grounds available." M.P.E.P. §707.07 (g). Further, "[w]here a 
major technical rejection is proper, it should be stated with a full development of 
reasons." Id. Further, the Examiner's action should be complete as to all matters. 
37 C.F.R. 1.104 and M.P.E.P. §707.07(a). In this instance, the Examiner has 
failed to detail reasons why the above referenced dependent claims are rejected. 
Therefore, the Examiner has also failed to give the Applicant an opportunity to 
refute those reasons. Accordingly, it is respectfully submitted that the finality of 
the rejection is in error and a new office action is earnestly solicited and/or 
withdrawal of the rejections is respectfully requested. Should the Examiner fail to 
withdraw the finality or the rejection, the Applicant respectfully requests that the 
Examiner telephone the below signed Applicant's Attorney to discuss. 

New Claims 33-56 are allowable based on similar reasoning and therefore 
the Applicant will not further burden the record. Withdrawal of the rejection is 
respectfully requested. 

35 U.S.C. $102 (e) Rejection 

Claims 1, 2 and 9-11 are rejected under 35 U.S.C. § 102(e) as being 
anticipated by U.S. Patent No. 6,112,227 to Heiner (hereinafter, "Heiner") See 
Office Action, Page 6. Applicant respectfully traverses the rejection and reserves 
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the right to rebut the use of Heiner as a reference at a later time, such as to 



antedate the reference. The claims are amended to increase clarity and not in 

response to the asserted references and therefore the Applicant will address the 

original rejections below. 

With regards to Claim 1, it is respectfully submitted that the Examiner uses 

different devices at different times in Heiner in making the rejection. For 

example, the Examiner asserts the following portion of Heiner for "registering 

with a discovery machine a first user and a second user". 

If the source client is not on the reject list, the destination 
SMTP server holds the e-mail message in memory and 
requests that the source client proceed with a registration 
process, as indicated in step 120. There are many different 
ways in which the source client can register its e-mail 
address. In one advantageous implementation, the destination 
SMTP server sends a reply message to the source client and 
requests that the source client send back a reply message. 
When the destination SMTP server receives the reply 
message, the original e-mail message is "filtered-in" and 
released to the destination client. However, if the original 
message is junk e-mail produced by a robotic delivery 
program, the destination SMTP server will never receive a 
response to its reply message because the source client e-mail 
address does not exist. See Heiner, Col. 3, Lines 39-55. 

At any time, the destination client can add e-mail addresses 
and remove e-mail addresses from the accept and reject lists. 
See Heiner, Col. 4, Lines 24-26. 

The above asserted portions are silent as to how the registration process is 

performed. Further investigation of Heiner shows that the "registration process is 

successfully completed when the source client responds correctly". See Heiner, 

Col. 3, 61-62. Thus, the registration process described merely involves 
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registration of the source client with the destination SMTP server . Claim 1, 
however, recites "registering a first user that maintains a first client machine and a 
second user that maintains a second client machine with a discovery machine". 

The Examiner then asserts that Heiner discloses "the discovery machine 
establishing a direct link between the first client machine and the second client 
machine; and delivering the communication" See Office Action, Page 7. The 
Examiner cites the following portion of Heiner to support this assertion, "In all 
implementations, if the source client's email address is on the accept list, the 
destination SMTP server sends the e-mail message to the destination client, as 
indicted in step 90". See Heiner, Col. 3, Lines 23-26. Thus, in this instance it is 
now the destination SMTP server that sends the e-mail message to the destination 
client , and not the source client. Consequently, a direct link is not caused to be 
established between the first and second client machines described as recited in 
Claim 1. 

Heiner merely describes a filter. More specifically, Heiner illustrates a 

system with various servers and destination and source clients, but no direct links 

between those clients. Heiner only allows for direct interaction between a client 

and one of the servers, for example: 

In a first step 60, a source client composes an e-mail message 
and the message is sent to the source SMTP server. Then in 
step 70, the source SMTP server sends the e-mail message to 
the destination SMTP server. In step 80, the SMTP server 
compares the source client's e-mail address to an accept list. 
The accept list contains the e-mail addresses of source clients 
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from which the destination client wishes to receive e-mail 
messages. See Heiner, Col. 3, Lines 10-20. 

Therefore, Heiner describes a multiple step process in which an e-mail is sent to 

various sources and authenticated before it is finally sent on to its intended 

destination, as opposed to the claimed "direct link" feature. Accordingly, it is 

respectfully submitted that Heiner does not disclose a direct link. 

For at least the above reasons, it is respectfully submitted that a prima facie 
case of anticipation has not been established and withdrawal of the rejection is 
respectfully requested. 

Claims 2 and 9-11 depend either directly or indirectly from claim 1 and are 
allowable as depending from an allowable base claim. Each of the dependent 
claims is allowable based on the same rationale discussed with respect to claim 1 . 
These claims are also allowable for their own recited features which, in 
combination with those recited in claim 1 , are neither shown nor suggested in the 
references of record, either singly or in combination with one another. 

For example, in rejecting claim 2, the Examiner asserts that Heiner 
discloses, "wherein the direct link closes after the communication is delivered; 
(after delivery of the message). See Office Action, Page 6. 

However, as before the Examiner does not cite any portion of Heiner in 
rejecting claim 2. As the Examiner is aware, the Examiner "ordinarily should 
reject each claim on all valid grounds available." M.P.E.P. §707. 07(g). Further, 
"[w]here a major technical rejection is proper, it should be stated with a full 
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development of reasons." Id. Further, the Examiner's action should be complete 
as to all matters. 37 C.F.R. 1.104 and M.P.E.P. §707. 07(a). In this instance, the 
Examiner has failed to detail reasons why the above referenced dependent claims 
are rejected. Therefore, the Examiner has also failed to give the Applicant an 
opportunity to refute those reasons. Accordingly, it is respectfully submitted that 
the finality of the rejection is in error and a new office action is earnestly solicited 
and/or withdrawal of the rejections is respectfully requested. Should the Examiner 
fail to withdraw the finality or the rejection, the Applicant respectfully requests 
that the Examiner telephone the Applicant's Attorney to discuss. 

Regardless, for the same reasoning as is stated above, Heiner is silent as to 
closing a direct link as there never is a direct link established between clients for 
communication in the first place. New Claims 33-56 are allowable based on 
similar reasoning and therefore the Applicant will not further burden the record. 
Withdrawal of the rejection is respectfully requested. 

35 U.S.C. § 103(a) Rejection 

Claims 1-4, 6-8 and 13 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over U.S. Patent No. 5,054,019 to Mathis et al. (hereinafter 
"Mathis") in view of U.S. Patent No. 6,941,148 to Hansmann et al. (hereinafter 
"Hansmann"). The Applicant respectfully traverses the rejection and reserves the 
right to challenge use of the asserted references by the Examiner at a later time, 
such as to antedate the references. The claims are amended to increase clarity and 
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not in response to the asserted references and therefore the Applicant will address 



the original rejections below. 

In rejecting claim 1, the Examiner first asserts Mathis. However, Mathis 

merely describes a first node and a second node, and does not teach or suggest a 

third device such as the discovery machine as recited in Claim 1 . Because of the 

lack of teaching or suggestion of a third device, Mathis is merely relied upon to 

support communication between a first and second node: 

In some situations, it is necessary for a local node to be able 
to transmit data to and receive data from a remote node in a 
single transaction. This prevents interference from third party 
nodes during the time between closing of a transmission link 
in one direction and initiating a new link in the other 
direction. See Mathis, Col. 1, Line 51-55. 

Thus, the expressed purpose of Mathis is to provide for communication between 

two devices in a single atomic link that does not involve any other devices. 

Accordingly, Mathis cannot be said to teach or suggest a system having more than 

two devices. 

The Examiner then correctly asserts the following: 

Mathis does not disclose the first user and the second user 
registering with a discovery machine, wherein the discovery 
machine is coupled to the network; wherein the 
communication is initiated via the discovery machine; the 
discovery machine determining that the first user will accept 
the communication; the discover machine establishing a 
direct link between the first client machine and the second 
client machine; wherein at least one of the first user and the 
second user maintains a plurality of contact information; 
wherein an individual entry in the plurality of contact 
information is automatically updated when an associated user 
of the individual entry updates a corresponding entry locally 
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at a client machine of the associated user; wherein a third user 
can initiate a new communication to at least one of the first 
and the second user via a web page interface coupled to the 
discovery machine; wherein the discover machine is a central 
server. See Office Action, Pages 8-9. 

To correct these defects, the Examiner asserts Hansmann as follows: 

Hansmann discloses a device registry for automatic 
connection, whereby one or more user devices registers with 
a central registry server then submits a request to access a 
service by selecting an icon on the user's display, and 
wherein the request is forwarded to the central registry server, 
which mates the request to a backend system providing the 
service; wherein the user device maintains a list of registry 
server address. See Office Action, Page 9. 

The following portion of Hansmann is referenced to support the above assertion: 

The user of the device-when he wants to perform any desired 
business process-selects a business process, e.g., by selecting 
a respective icon visible on the display. The icon represents 
either a particular device application, e.g., a flight reservation 
front end application, or it just represents a possibility, i.e., an 
option to perform a particular set of business processes, 
which are related to some general topic, as e.g., 'travelling'- 
associated with a symbolized aircraft icon. Behind said 
item/icon a program is implemented establishing a connection 
to a particular service provider or a group of providers. Upon 
receiving a double-click on said icon, i.e., start of said 
communication program an inventional Device Registry 
Server, further referred to and abbreviated herein as DRS is 
then connected via e.g., a mobile radio communication to the 
device... 

The pervasive device can advantageously store a plurality of 
DRS addresses. Advantageously, a DRS is associated with a 
particular service provider, as e.g., a travel agency... See 
Hansmann, Col. 2, Lines 40-55 and 65-67. 

However, Hansmann merely describes a system in which a user, using a system of 
icons, accesses a business process through a device registry server by clicking an 
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icon. Double-clicking of the icon is used to establish "a connection to a particular 
service provider or a group of providers". Id. However, this is the sole teaching 
relied upon by the Examiner from Hansmann, which does not overcome the above 
detailed deficiencies of Mathis, alone or in combination with Mathis. 

To purportedly support a reading of these features, the Examiner asserts 
that it "would be obvious of ordinary skill in the art at the time the invention was 
made for the first user and the second user to register with a discovery machine, 
wherein the discovery machine is coupled to a network..." See Office Action, 
Page 9. Additionally, the Examiner further states that the device in Hansmann 
scales well and "...enables a user device to connect with ever increasing services 
in a flexible manner without knowing in advance which backend system provides 
the required service. See Office Action, Page 9. The Examiner further asserts the 
following portion of Hansmann, "...any time at any place, it is necessary that 
these devices can connect to many different backend systems in a flexible way 
without knowing in advance which backend system will hold the user-required 
data whereby a minimum extent of customization work for the PD-user should be 
tolerated in view of an envisaged increased user comfort" See Hansmann, Col. 2, 
Lines 1-6. 

Regardless, it is respectfully submitted that these assertions still do not 
teach or suggest the features of Claim 1 alone or in combination with any of the 
asserted references, e.g., "determining", "wherein said direct link is not 
established if said first user does not accept said communication", and so on. 
Rather, these assertions and the asserted portions of Mathis and Hansmann merely 
result in a collection of elements that together would not result in the features of 
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claim 1 . This collection is not supported by a teaching or suggestion within the 
asserted references as to how these elements would function together. Indeed, it is 
respectfully submitted that the modification proposed by the Examiner runs 
counter to the expressed purpose of the asserted references. As previously 
described, Mathis merely describes communication between two nodes. Indeed, 
inclusion of more than one node is taught away by Mathis as shown in the 
following excerpt: 

In some situations, it is necessary for a local node to be able 
to transmit data to and receive data from a remote node in a 
single transaction. This prevents interference from third party 
nodes during the time between closing of a transmission link 
in one direction and initiating a new link in the other 
direction. See Mathis, Col. 1, Line 51-55. 

Thus, the deficiencies of Mathis, e.g., Mathis lacking a discovery machine and a 

server, cannot be overcome by the purported flexibility in Hansmann as this 

teaches away from the purpose of Mathis. Withdrawal of the rejection is 

respectfully requested. 

Claims 2, 4, 6-8 and 13 depend either directly or indirectly from claim 1 
and are allowable as depending from an allowable base claim. Each of the 
dependent claims is allowable based on the same rationale discussed with respect 
to claim 1 . These claims are also allowable for their own recited features which, in 
combination with those recited in claim 1 , are neither shown nor suggested in the 
references of record, either singly or in combination with one another. 

For example, claim 3 recites, "The method as recited in claim 1 , wherein if 
said first user is not available to receive said communication, said communication 
is stored by said discovery machine until said first user becomes available". In 
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rejecting claim 3, the Examiner asserts that in addition to claim 3 being 
unpatentable over Mathis in view of Hansmann, Hansmann also: 

...discloses that the registry server establishes a connection to 
the backend system through its backend router, wherein the 
router holds tables which define on which backend system the 
required application is installed. It is further notoriously well 
known in the art for routers to implement queuing disciplines; 
for example in the event that a destination is not available, a 
router implementing a fair queuing technique will queue the 
flow directed to a nonresponsive destination. Official notice 
of this teaching is taken. See Office Action, Page 10. 

The cited portion of Hansmann is, "Then, the Registry Server establishes a 

connection to the backend system via its backend router. The router holds tables 

that define on which backend system the required application is installed." See 

Hansmann, Col. 3, Lines 38-43. Hansmann merely describes the storage of data 

and tables, and not actual communication that has yet to be delivered. In essence, 

the storage of data and tables in Hansmann is described as a kind of map for 

finding installed applications, which no teaching or suggestion beyond that. 

Withdrawal of the rejection is respectfully requested. 

Claim 12 was rejected under 35 U.S.C. §103 (a) as being unpatentable over 

Mathis in view of Hansmann, and further in view of U.S. Patent No. 6.185,61 1 to 

Waldo et al. (hereinafter, Waldo). Claim 12 recites, "The method as recited in 

claim 1, wherein determining that said first user will accept said communication 

further comprises the step of storing notification of said communication if said 

first user is unavailable". The Examiner asserts (as Applicant also concluded 

above) that while, "Neither Mathis nor Hansmann disclose the step determining 

that the first user will accept the communication further comprises the step of 

storing notification of the communication if the first user is unavailable" See 
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Office Action, Page 11. The Examiner then states that "Waldo discloses a lookup 
service in a distributed network system that enables registered clients to be 
notified of the status of a service, including if a service is not available." See 
Office Action, Page 11. The Examiner then cites the following portions of Waldo: 

By receiving such a notification, clients can avoid attempting 
to access a service that is no longer available and can make 
use of new services as soon as they are added to the lookup 
service. In accordance with methods consistent with the 
present invention, a method is provided in a data processing 
system having a lookup service with associated services. This 
method receives a request by the lookup service for 
notification when the lookup service is updated, determines 
when the lookup service is updated, and generates a 
notification when it is determined that the lookup service is 
updated. See Waldo, Col. 2, Line 60-Col. 3, Line 2 



and in addition: 



Figure 4 depicts a flow chart of the steps performed by the 
lookup service when performing event-related processing. 
Initially the lookup service receives registrations from a 
number of clients interested in receiving notifications when 
particular events occur (step 402). In this step, the lookup 
service receives the registrations via invocation of the 
notification method on the lookup service interface and stores 
into a table, known as the event table, all of the associated 
information, such as an indication of the event in which the 
client is interested. It should be noted that a client may 
register to be notified upon the occurrence of an event, or the 
client may register for a third party to be notified. After 
receiving the registrations, the lookup service determines 
whether an event occurred such that at least one client has 
registered an interest in the event (step 404). The lookup 
service makes this determination by identifying when, for 
example, a new service has been added to the lookup service, 
an existing service has been deleted from the lookup service, 
or the attributes of a service have been modified. If such an 
event has not occurred, the event notification process of the 



SBMC, p.i 



25 



lookup service remains in a wait state. However, if an event 
has occurred, the lookup service determines all clients 
registered for notification for this event (step 406). This 
lookup service makes this determination by accessing the 
event table. Next the lookup service invokes each callback 
routines registered for each client identified in step 406 (step 
408). In this step, the event table contains a reference to the 
callback routine, passing the registered objects as parameters, 
to notify the clients of the occurrence of the event. See Waldo, 
Col. 11, Line 54-Col. 12, Line 18. 

However, Waldo merely discloses a notification system, similar to a reminder 
system. Waldo fails to teach the claimed feature of "...storing notification of said 
communication if said first user is unavailable", and in fact only determines which 
data to transfer based on whether a user is registered. This determination is not 
based on user availability, alone or in combination with the other asserted 
references. In essence, Waldo's system allows for data delivery to an unavailable 
user as long as that user is registered. Therefore, the system described by Waldo is 
only capable of notifying users as soon as an event occurs and not on the basis of 
user availability. 

New Claims 33-56 are allowable based on similar reasoning and therefore 
the Applicant will not further burden the record. Accordingly, it is respectfully 
submitted that a prima facie case of obviousness has not been established and 
withdrawal of the rejection is respectfully requested. 
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Conclusion 

Pending claims 1-13 and 34-56 are in condition for allowance, and 
Applicant respectfully requests issuance of the subject application. If any issues 
remain that preclude issuance of the application, the Examiner is urged to contact 
the undersigned attorney before issuing a subsequent Action. 

Respectfully Submitted, 

Dated: October 13, 2008 By: /William J. Breen, III/ 

William J. Breen, III 
Reg. No. 45,313 
509.755.7253 
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